Skip to content

Conversation

@eemeli
Copy link
Collaborator

@eemeli eemeli commented Jan 20, 2025

As discussed previously (most recently in #974 (comment)), we should update our terminology to no longer refer to a "function registry", a term that we don't actually define.

This PR applies that change, along with some incidental cleanup. The term default function is introduced, and used where appropriate.

The GitHub label registry should probably also be renamed as default-functions.

@eemeli eemeli added the functions Issue pertains to the default function set label Jan 20, 2025
@eemeli eemeli requested a review from aphillips January 20, 2025 20:07
Copy link
Member

@aphillips aphillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some food for thought comments. Otherwise looks good.


Implementations MUST _accept_ each **REQUIRED** _function_ and
MUST _accept_ all _options_ defined as **REQUIRED** for those _functions_.
Implementations MUST _accept_ each REQUIRED _default function_ and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't make this change: I don't think it is necessary.


_Functions_ can define _options_.
An _option_ can be **REQUIRED** or **RECOMMENDED**.
An _option_ can be REQUIRED or RECOMMENDED.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The formatting here is intentional. Many such below. Won't repeat.

@aphillips
Copy link
Member

About the label: I was waiting to rename it based on discussion of what the name should be 😉

Copy link
Member

@aphillips aphillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ready for merge per 2025-02-10 call, except for my comments

Comment on lines 389 to 391
> [!NOTE]
> The option `select` does not accept the value `ordinal` because selecting
> currency values using ordinal rules makes no sense.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this (and line 523) doesn't work because it is a normative directive in a note. We should either override the option select in this function or we should make this IMPORTANT

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed these notes, as the select option was removed from :currency and :unit functions in #991.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, needed to force-push a fix, as this and a few other problems were due to the preceding merge applying incorrect changes.

Comment on lines 523 to 525
> [!NOTE]
> The option `select` does not accept the value `ordinal` because selecting
> unit values using ordinal rules makes no sense.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above comment on line 391

@aphillips
Copy link
Member

Per discussion in the 2025-02-10 teleconference, I am merging these changes. Others might be needed to meet v47 release criteria.

@aphillips aphillips merged commit 7963d9c into main Feb 13, 2025
1 check passed
@aphillips aphillips deleted the dereg branch February 13, 2025 23:10
@eemeli eemeli added this to the LDML 47 milestone Jul 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

functions Issue pertains to the default function set

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants